After analyzing the stack traces in #136, we now have a very good understanding of what is happening:

• A stream resource is both waiting to write outgoing data and accepting incoming data
• The event loop notifies the stream is readable
• The stream component detects a stream is closed by the remote end (strlen(fread()) === 0)
• The stream component first removes the read listener from the event loop (and after this would also remove the write listener)
• The event loop tries to set the read-write stream listener to writable only
• ext-event complains that the stream is not a valid resource

I've added a number of tests as part of this PR to trigger this specific situation. However, while several tests now cover this specific situation, I've been unable to create a reliable, reproducible test where ext-event actually complains.

This means that we have a good understanding of what is failing and we can work around this issue. The updated code avoids this situation by using two separate stream watchers for the readable and writable side that can be removed independently instead of using a single watcher that needs to be updated.

The updated code has 100% code coverage and while I'm currently unable to provide a test case for the initial issue, I believe to have fixed a relevant bug anyway.

Accordingly, I've removed the WIP marker for now

For the reference: This is still a relevant bug fix, but we've finally fixed the root cause via reactphp/socket#141 👍

The issue boils down to a bug where react/socket issued fclose() on the stream resource before passing it to removeReadStream().